home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20041116-20060924 / 000349_JDanSkinner@JDanSkinner.com_Sat May 13 10:51:45 2006.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB

  1. Path: newsmaster.cc.columbia.edu!panix!newsfeed-00.mathworks.com!newscon06.news.prodigy.com!prodigy.net!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!j73g2000cwa.googlegroups.com!not-for-mail
  2. From: JDanSkinner@JDanSkinner.com
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: Script compiling / encrypting?
  5. Date: 12 May 2006 16:04:21 -0700
  6. Organization: http://groups.google.com
  7. Lines: 56
  8. Message-ID: <1147475060.983681.275370@j73g2000cwa.googlegroups.com>
  9. References: <1147371315.638050.245860@j73g2000cwa.googlegroups.com>
  10.    <slrne6751c.r56.fdc@sesame.cc.columbia.edu>
  11.    <1147450786.063942.270090@i39g2000cwa.googlegroups.com>
  12.    <PV29g.42916$nA3.30482@news-wrt-01.rdc-nyc.rr.com>
  13. NNTP-Posting-Host: 24.159.192.106
  14. Mime-Version: 1.0
  15. Content-Type: text/plain; charset="iso-8859-1"
  16. X-Trace: posting.google.com 1147475066 6559 127.0.0.1 (12 May 2006 23:04:26 GMT)
  17. X-Complaints-To: groups-abuse@google.com
  18. NNTP-Posting-Date: Fri, 12 May 2006 23:04:26 +0000 (UTC)
  19. In-Reply-To: <PV29g.42916$nA3.30482@news-wrt-01.rdc-nyc.rr.com>
  20. User-Agent: G2/0.2
  21. X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3,gzip(gfe),gzip(gfe)
  22. Complaints-To: groups-abuse@google.com
  23. Injection-Info: j73g2000cwa.googlegroups.com; posting-host=24.159.192.106;
  24.    posting-account=5JPUcQwAAAB6TGKSwwkRxsWxWFx0QQ_3
  25. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15606
  26.  
  27.  
  28. Jeffrey Altman wrote:
  29. > quertyq wrote:
  30. > > Hi Frank,
  31. > >
  32. > > I am writing a program for our company to do
  33. > > file transferrs on the user's computers, and an
  34. > > FTP server which is used by a controlling
  35. > > program on the user's computers.  We would
  36. > > not want to use a shared file system because
  37. > > we do not want the users to have direct access
  38. > > to these files ... only controlled access through
  39. > > a program where they point & click.  We can
  40. > > also control permissions at the server level.
  41. > >
  42. > > The program may have to be updated from time
  43. > > ( on the user's computers ) to time to change
  44. > > logins, passwords, source & target directories,
  45. > > etc.   The only forseeable problem is how to
  46. > > conceal the code so that ambitious end users
  47. > > cannot open the source with an editor and "play".
  48. > >
  49. > > Since they use winxp, I'm at a loss on how to
  50. > > do this ( if it is even possible ).
  51. > >
  52. > > - Matt
  53. >
  54. > If the program runs in the user's account, then the
  55. > most you can do is obfuscate the information.  If the
  56. > program runs on the machine in a different account,
  57. > such as that belonging to a service, then you can
  58. > prevent the user's from being able to access the
  59. > details such as login info, locations, etc.
  60. >
  61. > If you set things up properly, then you can even
  62. > control the contents of the registry information for
  63. > the service by using Active Directory Group Policy
  64. > to push out changes to the machines.
  65. >
  66. > Personally, I would simply use a secure distributed
  67. > file system and grant the user's access to the appropriate
  68. > files on an as needed basis.  If you need to change the
  69. > locations, change the ACLs.
  70. >
  71. > Jeffrey Altman
  72.  
  73. An alternate approach is to use a wrapper program which contains the
  74. Kermit script in binary form, or encripted if you must.
  75. Execute the kermit script by launching the wrapper which writes the
  76. script to a temporary file then uses it to run the kermit transfer then
  77. deletes the temporary file,
  78. always deletes the temporary file.
  79. Not a perfectly secure solution, but reasonably so.
  80. If updates are required, simply replace the wrapper.
  81. Regards...Dan.
  82.